Method and program product for costing and planning the re-hosting of computer-based applications

ABSTRACT

A computer-implemented method and program product for estimating cost and/or time requirements for migrating an application from one platform to another. The method includes receiving identifications for tasks, receiving at least one assessment type selected for estimating cost and/or time requirement for migration, where the assessment type delineates a degree of accuracy for estimating the cost and/or time requirement for migration, correlating base costs and/or time requirements to the tasks identified, receiving identifications of attributes that affect base costs and/or time requirements, correlating cost and/or time factors to the tasks, a respective cost factor and/or time factor indicating an amount by which an attribute affects the respective base cost and/or time requirement for a task, and estimating cost and/or time requirements for each task, by applying the respective cost and/or time factors for each task to the respective base cost and/or base time requirements for each task.

REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of provisional application Ser. No.60/457,155, filed Mar. 24, 2003.

BACKGROUND OF THE INVENTION

1. Technical Field of the Invention

The invention relates generally to the field of methods for re-hostingcomputer-based applications. More specifically, the invention relates toa method and program product for costing and planning the re-hosting, ormigration, of computer-based applications from source computer-basedplatforms to target computer-based platforms.

2. Description of Related Art

The use of computer systems and applications greatly simplifies thestorage and processing of data. Nevertheless, the large volume of datathat a business processes in a short time period can cause the businessto become entrenched in its use of a particular platform orcomputer-based environment. By the time a significant advance is made,the business may be so mired within an antiquated system that it isforced to lose money each year due to the inefficiencies of the system.In response to this problem, methods and systems for migratingapplications among computer-based platforms have been developed.

Re-hosting applications from a source platform to a target platform canbe expensive, but a time typically arrives when the cost of continuinginefficiencies outweighs the cost of migration. A business must be ableto determine when it reaches this condition, in order to obtain the mostbenefit from its time and monetary expenditures on a migration.Nevertheless, while methods for migration have grown, businesses havebeen unable to estimate the cost for migration of applications withinuseful tolerances. Hence, businesses are prone to waste their resourcesby significantly undershooting or overshooting the point when migrationbecomes a cost-effective solution.

In addition to the cost of a migration project, a business also needs toallow for downtime and other lapses in its application and computersystem operations. Again, current migration methods overlook thislogistical question and only focus on the end result. A businessundergoing migration can suffer needlessly, then, due to an inability toplan precisely for the length of interruption in its operations. Thisadds to the true cost of migration, forcing some businesses to undergomigration of applications either sooner, or later, than it becomescost-effective.

As a result, there exists a great need in the art for a method ofestimating the cost of application migration, on a per applicationbasis, within specified tolerances. Additionally, there is a great needin the art for a method of estimating the time required for applicationmigration, on a per application basis, within specified tolerances. Themethod must provide a thorough analysis of factors that affect the costand time required for the migration of individual applications, in orderto overcome the inconsistencies and inaccuracies of ad hoc plans andcost estimates.

SUMMARY OF THE INVENTION

The current invention is directed to a method of estimating the cost ofapplication migration, on a per application basis. The invention is alsodirected toward a method for estimating the time required forapplication migration, on a per application basis. The method providesallows varying degrees of thoroughness in its analysis of migrationattributes that affect the cost and time required for the migration ofindividual applications between platforms. In this way, the inventionproduces consistent and reliable results with a degree of accuracy thatis genuinely valuable to the particular user.

The current invention provides a computer-implemented method forestimating the cost and/or time requirements for migrating acomputer-based application from a source platform to a target platform.The invented method comprises the steps of receiving identifications ofsaid migration tasks; correlating base costs to respective ones of saidmigration tasks; receiving identifications of migration attributes;correlating cost factors to respective ones of said migration tasks,each cost factor indicating an amount by which a migration attributechanges the base cost of a migration task; and estimating a cost foreach migration task, by applying all cost factors for the migration taskto the base cost of the migration task.

The migration attributes that may be considered in estimating cost maycomprise one or more attributes, such as hardware attributes, operatingsystem attributes, application attributes, environment attributes,source code attributes, complexity attributes and testing attributes, asfurther described herein. One or more of the base costs and cost factorsmay be received from a user.

The invented method may also comprise applying tolerances to one or moreof the estimated costs and total cost, such that one or more of these isreturned as a cost range. At least one assessment type may be chosen ordefined by a user, such that the assessment observes the user's desireddegree of accuracy for the total cost and the cost of each migrationtask.

The invented method may comprise, in addition or in the alternative tocost estimation, steps for estimating time requirements for a migration.The steps required for estimating time may comprise correlating basetime requirements to respective ones of said migration tasks;correlating time factors to respective ones of said migration tasks,each time factor indicating an amount by which a migration attributechanges the base time requirement for a migration task; and estimating atime requirement for each identified migration task, by applying alltime factors assigned to the migration task to the base time requirementof the migration task.

The migration attributes that may be considered in estimating timerequirements may comprise one or more attributes, such as hardwareattributes, operating system attributes, application attributes,environment attributes, source code attributes, complexity attributesand testing attributes, as further described herein. One or more of thebase time requirements and time factors may be received from a user.

The invented method may also comprise applying tolerances to one or moreof the estimated time requirements and total time requirement, such thatone or more of these is returned as a time range. At least oneassessment type may be chosen or defined by a user, such that theassessment observes the user's desired degree of accuracy for the totaltime requirement and the time requirement for each migration task.

Where both time and cost for each migration task and/or for a totalmigration are estimated, they may be output on a common assessment.

Individual aspects or functions of the invented method may be embodiedin computer-readable program products. Hence the current invention isalso directed to computer-readable program code means for implementingand executing the steps of the methods disclosed, in a manner that willbe readily known to those skilled in the art.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram illustrating the invented method, wherein acost and/or time estimate for the migration of an application from asource platform to a target platform is output.

FIG. 2 is an illustration of an example embodiment of an assessmenttemplate.

FIG. 3 is a flow diagram further illustrating steps of the inventedmethod, wherein a Type C assessment is output, in accordance with thecurrent invention.

FIG. 4A is an illustration of an example embodiment of a base costmatrix.

FIG. 4B is an illustration of an example embodiment of a complexity costfactor matrix.

FIG. 5 is an illustration of an example embodiment of a hardware costfactor matrix.

FIG. 6 is an illustration of an example embodiment of an OS cost factormatrix.

FIG. 7 is an illustration of an example embodiment of an applicationcost factor matrix.

FIG. 8 is an illustration of an example embodiment of an environmentcost factor matrix.

FIG. 9A is an illustration of an example embodiment of a base timerequirement matrix.

FIG. 9B is an illustration of an example embodiment of a complexity timefactor matrix.

FIG. 10 is an illustration of an example embodiment of a hardware timefactor matrix.

FIG. 11 is an illustration of an example embodiment of an OS time factormatrix.

FIG. 12 is an illustration of an example embodiment of an applicationtime factor matrix.

FIG. 13 is an illustration of an example embodiment of an environmenttime factor matrix.

FIG. 14 is a flow diagram illustrating steps of the invented method,wherein a Type B assessment is output, in accordance with the currentinvention.

FIG. 15 is an illustration of an example embodiment of a code costfactor matrix.

FIG. 16 is a flow diagram illustrating steps of the invented method,wherein a Type A assessment is output, in accordance with the currentinvention.

FIG. 17 is an illustration of an example embodiment of a code timefactor matrix.

FIG. 18 is an illustration of an example embodiment of a testing costfactor matrix.

FIG. 19 is an ,illustration of an example embodiment of a testing timefactor matrix.

DETAILED DESCRIPTION OF THE INVENTION

Referring now to the drawings, the invention is directed to a method forcosting and planning the migration of an application amongcomputer-based environments. The individual steps of the method arepreferably executed by at least one computer software program embodiedon a computer-readable medium, without regard to the operating system ofthe computer or the language of the software programs. It will beappreciated by those skilled in the art that some steps of the methodmay be performed in series, and some in parallel or in series.Additionally, the order of the steps may in some instances be changed,without departing from the scope or advantages of the current invention.The order in the following embodiments is given only for ease ofexplanation.

FIG. 1 is a flow diagram illustrating a method for costing and planningthe migration of an application from a source computer-based environmentto a target computer-based environment, in accordance with the currentinvention. In accordance with step 101, a set of base variables isreceived. The base variables comprise an application to be migrated, asource platform on which the application currently operates, and atarget platform for the application.

In accordance with step 102, an assessment type is received. Theassessment types are referred to herein as Type C, Type B, and Type Aassessments. An assessment may comprise a cost estimate, a timeestimate, or both cost and time estimates, for migrating the applicationfrom the source platform to the target platform. Assessment types may bedelineated by the type or amount of information processed, in order tocalculate the cost and/or time estimate returned by the assessment.Assessment types may also be delineated by the degree of accuracy incost and/or time that the assessment is intended to entail. For purposesof this description, assessments are delineated by their intendedaccuracy, and, hence, by the type and amount of information gathered.

In accordance with step 103, an identifier for at least one migrationtask is received. The migration tasks may be user-defined, or they maybe chosen from a list of pre-defined migration tasks. Alternatively, aset of migration tasks may be associated with each assessment type, suchthat they are received automatically upon receipt of an assessment type.The individual migration tasks involved in migrating a specifiedapplication from a particular source platform to a particular targetplatform are readily known to those skilled in the art. Such migrationtasks may comprise, for example, system building, project management,ramp up, baseline testing, migration of the application from the sourceplatform to the target platform, system testing after migration,delivery of the migrated application, acceptance testing to validatethat the application can process data, project completion and sign-off,exporting data from the source platform and importing the data to theapplication on the target platform, redirecting user terminals to thetarget platform, replacing third party products that cannot be ported tothe target platform, and any other individual migration tasks that maybe involved in the migration of a computer-based application from asource platform to a target platform.

In accordance with step 104, at least one assessment template may becreated. An assessment template contains the names of the individualmigration tasks that will be involved in the migration, cross-referencedto the costs of such migration tasks. The migration tasks may also becross-referenced to time requirements for each migration task, such asduration of each task in work hours or days, and start and finish times.The migration tasks may be cross-referenced to any other informationsuitable for the planning and costing of individual migration projecttasks. In one embodiment, the assessment template comprises a form, suchas that shown by FIG. 2. Those skilled in the art will appreciate thatthis embodiment of the template is illustrative, and that othertemplates, including relational and associative forms may be usedwithout departing from the scope of the invented method.

The assessment template may be created upon receiving a plurality ofmigration tasks. Alternatively, an assessment template may be chosenfrom a plurality of pre-defined templates, each containing a differentsubset of migration tasks.

The cost of each migration task in the assessment template is shown in acolumn separate from that of the migration tasks, such that each cost isrepresented in the same row of the template as the migration task towhich it corresponds. For purposes of this description, the cost of eachmigration task ‘i’ will be represented by the function f(c_(i)). Thevariable ‘i’ may actually be represented as a priority number or anyother suitable number for sequentially identifying the migration tasksrepresented in the assessment template, such that the total cost of themigration process can be achieved by summing the costs of migrationtasks, 1 . . . i.

The template may also include a breakdown of costs, such as labor andmaterials, with or without reference to specific tasks.

At least one time requirement for each migration task in the assessmenttemplate may be shown in a column separate from those of the migrationtasks and costs, such that a time requirement is represented in the samerow of the assessment template as the migration task to which itcorresponds. For purposes of this description, the time requirement foreach individual task will be represented by the function f(t_(i)). Thevariable ‘i’ may actually be represented as a priority number or anyother suitable number for sequentially identifying the migration tasksrepresented in the assessment template, such that the total time for themigration process can be achieved by summing the time requirements formigration tasks, 1 . . . i. Where both time and cost are estimated onthe template, the variable ‘i’ shall be identical for both f(t_(i)) andf(c_(i)).

In accordance with step 105, a base cost is assigned to each migrationtask. Where time is being estimated, a base time is assigned to eachmigration task. The base cost comprises the average base cost for themigration task, when migrating the application received in step 101between the source and target platforms received in step 101. The basetime comprises the average base time requirement for the migration task,when migrating the application received in step 101 between the sourceand target platforms received in step 101. Base costs and base times maybe user-defined; may be chosen from a database; or may be automaticallyassigned from a database upon receipt of the base variables. Base costsand base times may vary depending upon the type of assessment to bereturned.

In accordance with step 106, attributes relevant to the migration arereceived. Migration attributes may include hardware attributes,operating system attributes, application attributes, environmentattributes, source code attributes, testing attributes, or anycombination of these. The various migration attributes are described infurther detail below.

For each migration attribute received, a cost factor is assigned to eachidentified migration task, in accordance with step 107. Each cost factorrepresents the amount by which the attribute changes the base cost of amigration task. Where time is being estimated, a time factor is assignedto each migration task. Each time factor represents the amount by whichthe attribute changes the base time of each migration task. Cost andtime factors may comprise proportions that are greater than, less than,or equal to, one. Cost and time factors may be input by users; they maybe chosen from a database of cost and time factors; or they may beautomatically called from a database in the forms of cost and timefactor matrices relevant to the attributes and base variables, asfurther described below.

In accordance with step 108, the cost factors assigned to each migrationtask are applied to the base cost for the migration task, as furtherdescribed herein. This results in an estimated cost for each migrationtask. Time factors assigned to each migration task are applied to thebase times for the migration task, as further described herein. Inaccordance with step 109, tolerances may be applied to the cost and/ortime for individual migration tasks. The cost and/or time for themigration tasks are then summed to achieve a total cost and/or timerequirement for the migration. Finally, in accordance with step 110, anassessment of the type received in step 102 is output, containing theestimated cost and/or time requirement for the migration. The assessmentmay conform to the assessment template created in step 104, if any. Theestimates for cost and time may comprise fixed numbers or ranges. Theassessment may also contain cost and/or time estimates for individualmigration tasks, which estimates may be fixed numbers, ranges, or acombination of fixed numbers and ranges.

The steps of the invented method are described in further detail below,with specific references to the different types of assessments and theassignment of base costs and times, and cost and time factors.

FIG. 3 is a flow diagram illustrating a method for returning a Type Cassessment for the migration of an application from a source platform toa target platform, in accordance with the current invention. Inaccordance with step 301, base variables are received, which comprise anapplication to be migrated, a source platform on which the applicationcurrently operates, and a target platform on which the application is tobe re-hosted.

The application variable may comprise a specific application name andversion. Alternatively, the application may include the function of theapplication and (if more than one function) its component parts, such asproduction control, batch processing, data mining, online transactionprocessing (OLTP), or other functions. In the preferred embodiment ofthe invention, the application variable comprises the name, version andfunction(s) of the application and its component parts.

The source and target platform variables may comprise any platformssuitable for operating the computer-based application to be migrated.These platforms may include, for example, UNIX (generic or variants),OpenVMS, IBM AS/400 or iSeries, HP 300 MPE, IBM Mainframe, and otherplatforms that are readily known to those skilled in the art.

In accordance with step 302, a user's choice of a Type C assessment isreceived. In accordance with step 303, an identifier for at least onemigration task is received, as described with reference to FIG. 1. Inaccordance with step 304, an assessment template may be created in themanner described with reference to FIG. 1. The assessment template for aType C assessment preferably comprises a high-level representation ofmigration tasks, as distinguished from a Type B or Type A assessmenttemplate. A Type C template may also comprise just a total figure forcost and/or time.

In accordance with step 305, base costs and/or times are assigned toeach migration task. For a Type C assessment, the base variables arepreferably compared with at least one base cost matrix in a database.Each base cost matrix sets forth an average base cost for migrationtasks, such as those listed previously. A base cost matrix may conformsubstantially to that shown in FIG. 4A, wherein migration tasks arelisted in one column, and a base cost is shown in the row containing amigration task to which the base cost corresponds. A base cost, ^(i)β,is extracted from the database, for each migration task, T, received instep 303. Note that each base cost matrix may contain base cost data formore migration tasks than are received in step 303.

Each base cost matrix may set forth average costs for migration tasks,with respect to specific applications. Alternatively, each base costmatrix may set forth average base costs for migration tasks, withrespect to the degree of commonality of various applications. Forexample, base cost matrices may be built for standard applications (forexample, word processors and data storage), non-standard (such ascompilers and communication software), and custom-made applications.Matrices may be built to reflect additional qualitative categories ofapplications that have a quantifiably distinguishable effect on the costof at least one migration task.

Where time requirements are being estimated, base time requirements areassigned to each migration task. For a Type C assessment, the basevariables are preferably compared with at least one base time matrix ina database. Each base cost matrix sets forth an average base cost formigration tasks, such as those listed previously. A base timerequirement matrix may conform substantially to that shown in FIG. 9A,wherein migration tasks are listed in one column, and a base timerequirement is shown in the row containing a migration task to which thebase time requirement corresponds.

A base time, ^(i)T, is extracted from the database, for each migrationtask, ‘i’, received in step 303. Note that each base cost matrix maycontain base time data for more migration tasks than are received instep 303.

Each base time requirement matrix may set forth average timerequirements for migration tasks, with respect to specific applications.Alternatively, each base time matrix may set forth average base timerequirements for migration tasks, with respect to the degree ofcommonality of various applications. For example, base time matrices maybe built for standard applications (for example, word processors anddata storage), non-standard (such as compilers and communicationsoftware), and custom-made applications. Matrices may be built toreflect additional qualitative categories of applications that have aquantifiably distinguishable effect on the time requirement for at leastone migration task.

In accordance with step 306, at least one migration attribute isreceived. The migration attributes may comprise, for example, hardwareattributes, current operating system attributes, attributes of theapplication to be migrated, environment attributes, or testingattributes. Hardware attributes include elements of source and targetplatform hardware architecture, which affect the complexity of migratingan application or porting data between the source and target platforms.Examples of hardware attributes may include, for example, clustering,disks, external interfaces, archive media, memory, networking, media,processors, terminal types (e.g., dumb, emulated), workstations,third-party hardware elements, byte storage sequence (e.g., big endian,little endian) and other aspects of hardware architecture that impactthe process of migrating an application or porting data a sourceplatform and a target platform.

Operating system attributes may comprise the type and version of thesource platform's current operating system(s).

The application attributes comprise attributes of the application thatmay affect the cost and plan for migrating the application, other thanthe overall function(s) of the application. Application attributes maycomprise, for example, whether the application is real-time; missioncritical; user interactive; used for production control, batchprocessing, data mining, on-line transaction processing (OLTP), or otherrelevant attributes that may affect the cost and plan for migrating theapplication. Application attributes may be expressed in descriptiveform, or as yes-no (or other analogous binary system) indicators forpre-defined attributes.

Environment attributes may comprise any attributes of the softwareenvironment, in which the application is operated on the sourceplatform, that may affect the cost or plan for migrating theapplication. Environment attributes may comprise, for example,development languages; databases and other data storage and accessattributes; user interfaces; communication transport protocols;networking attributes; shell script usage; security attributes; batchprocessing characteristics; and other attributes of the softwareenvironment in which the application is operated on the source platform,that may affect the cost or plan for migrating the application.

Testing can be used as a measurement of progress during migration, andit can limit debugging time afterward. Testing itself, however, can havea significant impact upon the time and cost for a migration. Testingduring a migration may comprise baseline testing, i.e., testing theapplication on the source platform before it is migrated. Testing mayalso comprise system testing, i.e., testing the application aftermigration. A set of criteria may be established for verifying properperformance of the application. Both the baseline testing results andthe system testing results are compared with the criteria, such thatproper performance of the application can be verified both before andafter the migration of the application between platforms.

Testing attributes may comprise any inventory and criteria that mightimpact upon the length of time or cost for baseline or system testing.Such information may include, for example, the need to create testingprograms; whether baseline or system testing requires visits to othersites; the need to setup the application or the testing programs priorto baseline testing; any need to rebuild the application in a cleanenvironment prior to testing; the testing process itself; verifying testresults and comparing them to criteria; and debugging of the applicationafter migration. Testing attributes may also comprise the types oftesting to be performed, such as unit tests (subroutine level) andwhether unit testing will be performed as the application is ported tothe new platform; functional tests (tests of user functions) testing ofbatch processes; integration tests (program level tests of theapplication's external interfaces); regression tests (movement of databetween user functions); performance tests; system management tests(start-up, shutdown, etc.); and hardware tests.

In accordance with step 307, cost and/or time factors corresponding toeach migration attribute received in step 306, and corresponding to thebase variables, are assigned to each migration task. For a Type Cassessment, the assignment of cost factors is preferably achieved by auser choosing attributes from pre-defined lists. The attributes are thencompared with at least one cost factor matrix in a database. Each costfactor matrix contains cost factors for various migration tasks, when atleast one attribute is relevant to migrating a specified applicationfrom a specified source platform to a specified target platform. Eachcost factor matrix may set forth factors for migration tasks, withrespect to specific applications. Alternatively, each cost factor matrixmay set forth cost factors for migration tasks, with respect to thedegree of commonality of various applications. For example, cost factormatrices may be built for standard applications (for example, wordprocessors and data storage), non-standard (such as compilers andcommunication software), and custom-made applications. Matrices may bebuilt to reflect additional qualitative categories of applications thathave a quantifiably distinguishable effect on the cost of at least onemigration task. Various cost factor matrices are described in furtherdetail, below.

One example of a cost factor matrix contemplated for returning a Type Cassessment is a complexity cost factor matrix. Each complexity costfactor matrix sets forth factors, comprising the amounts by which thecosts of various migration tasks are changed by the complexity ofmigrating an application between a source platform and a targetplatform. A complexity cost factor matrix may conform substantially tothat shown in FIG. 4B, wherein a complexity cost factor, is shown at theintersection of each row containing a migration task, ‘i’, and a columncontaining a source-target combination, ‘S-T’. Note that a complexitycost factor matrix may contain complexity cost factors for moremigration tasks than are received in step 303.

The factors may comprise proportions by which the base costs ofmigration tasks may be multiplied to reflect the effect of thesource-target combination in increasing, decreasing or not affecting,the average base cost of migration tasks during a migration process. Theeffect of various source-target combinations upon the base cost of eachmigration task, and hence the development of each complexity costfactor, ^(i)λ_(S−T), will be readily appreciated by those skilled in theart.

A single universal complexity cost factor matrix may be used, or manycomplexity cost factor matrices may be used, each one containing factorsfor only one type of source-target combination, such as UNIX-UNIX;Generic UNIX-UNIX Variant; AIXv(x)-AIXv(x+1); Windows XP-Solaris/Intel;and the like. Species of source and target platforms may beparticularized (such as Bull GCOS, DG DG-UX, FreeBSD, HP HP-UX, HP MPE,HP NSK, HP OpenVMS/Alpha, HP OpenVMSNAX, HP Tru64 UNIX, HP VMSNAX, IBMAIX, IBM DOSNSE, IBM DYNIX/ptx, IBM MVS, IBM OS/390, IBM zOS, IntelLinux, SCO UnixWare, SGI Irix, Solaris/Intel, Solaris/SPARC, Windows 9x,Windows NT/200, Windows XP and the like). Species of source and targetplatforms may be non-particularized (such as common platform, uncommonplatform, custom platform, proprietary platform, and the like).Particularized and non-particularized species may be combined on asingle complexity cost factor matrix and in individual source-targetcombinations (such as WinXP-proprietary platform).

Once at least one complexity cost factor matrix is identified thatreflects the source-target combination received in step 301, acomplexity cost factor, ^(i)λ_(S−T), for each migration task, ‘i’, inthe assessment template is obtained from the complexity cost factormatrix or matrices. Note that ^(i)λ_(S−T) may differ for each migrationtask.

Another type of cost factor matrix that may be used in returning a TypeC assessment is a hardware cost factor matrix. Each hardware cost factormatrix sets forth factors, comprising the amounts by which the costs ofvarious migration tasks are changed due to the presence of at least onehardware attribute during migration. A hardware cost factor matrix mayconform substantially to that shown in FIG. 5, wherein a hardware costfactor, ^(i)h_(k), is shown at the intersection of each row containing amigration task, ‘i’, and a column containing a hardware attributecombination, ‘k’. Note that a hardware cost factor matrix may containhardware cost factors for more migration tasks than are received in step303.

The factors may comprise proportions by which the base costs ofmigration tasks may be multiplied to reflect the effect of at least onehardware attribute in increasing, decreasing or not affecting, theaverage base costs of the migration tasks during a migration process.The effect of various hardware attribute combinations upon the base costof each migration task, and hence the development of each hardware costfactor, ^(i)h_(k), will be readily appreciated by those skilled in theart.

A single universal hardware cost factor matrix may be used, or manyhardware cost factor matrices may be used, each one containing factorsfor only one type of hardware attribute combination, such as externalinterface combinations, media combinations, byte storage sequencingcombinations, and the like. Species of hardware attributes may beparticularized (such as big endian to little endian, and the like).Species of hardware attributes may be non-particularized (such as,standard connectivity to non-standard connectivity, common processors tocustom processors, and the like). Particularized and non-particularizedspecies may be combined on a single hardware cost factor matrix.

Once at least one hardware cost factor matrix is identified containingthe hardware attribute combinations, 1 . . . k, which were received inaccordance with step 306, the hardware cost factors, ^(i)h_(k), for eachmigration task in the assessment template are obtained from the hardwarecost factor matrix or matrices. Note that ^(i)h_(k) may differ for eachmigration task.

Another type of cost factor matrix that may be used in returning a TypeC assessment is an operating system (OS) cost factor matrix. Each OScost factor matrix sets forth factors, comprising the amounts by whichthe costs of various migration tasks are changed due to the operatingsystem operated on the source platform (due to, for example, threads,embedded SQL/RDBMS access, kernel mode routines, clusteringfunctionality, operating system intrinsics, library functions, etc.). AnOS cost factor matrix may conform substantially to that shown in FIG. 6,wherein an OS cost factor, ^(i)ω_(m), is shown at the intersection ofeach row containing a migration task, ‘i’, and a column containing anoperating system, ‘m’. Note that an OS cost factor matrix may contain OScost factors for more migration tasks than are received in step 303.

The factors may comprise proportions by which the base costs ofmigration tasks may be multiplied to reflect the effect of the OSoperated on the source platform in increasing, decreasing or notaffecting, the average base costs of the migration tasks during amigration process. The effect of various operating systems upon the basecost of each migration task, and hence the development of each OS costfactor, ^(i)ω_(m), will be readily appreciated by those skilled in theart.

A single universal OS cost factor matrix may be used, or many OS costfactor matrices may be used, each one containing factors for only onetype of operating system. Species of operating systems may beparticularized (such as Microsoft Windows® NT, Sun Solaris® and thelike). Species of operating systems may be non-particularized (such as,standard, non-standard, custom, and the like). Particularized andnon-particularized species may be combined on a single OS cost factormatrix.

Once at least one OS cost factor matrix is identified containing theoperating systems, 1 . . . m, which were received in accordance withstep 306, the OS cost factors, ^(i)ω₁ . . . ^(i)ω_(m), for eachmigration task in the assessment template are obtained from the OS costfactor matrix or matrices. Note that ^(i)ω₁ . . . ^(i)ω_(m), may differfor each migration task.

Another type of cost factor matrix that may be used in returning a TypeC assessment is an application cost factor matrix. Each application costfactor matrix sets forth factors, comprising the amounts by which thecosts of various migration tasks are changed due to at least oneattribute of the application being migrated. An application cost factormatrix may conform substantially to that shown in FIG. 7, wherein anapplication cost factor, ^(i)α_(n), is shown at the intersection of eachrow containing a migration task, ‘i’, and a column containing anapplication attribute, ‘n’. Note that an application cost factor matrixmay contain application cost factors for more migration tasks than arereceived in step 303.

The factors may comprise proportions by which the base costs ofmigration tasks may be multiplied to reflect the effect of applicationattributes in increasing, decreasing, or not affecting, the average basecosts of the migration tasks during a migration process. The effect ofeach application attribute upon the base cost of each migration task,and hence the development of each application cost factor, ^(i)α_(n),will be readily appreciated by those skilled in the art.

A single universal application cost factor matrix may be used, or manyapplication cost factor matrices may be used, each one for a singleapplication attribute, such as real-time operation, OLTP, and the like.Species of applications may be non-particularized (such as, standard,non-standard, custom, and the like). Particularized andnon-particularized species may be combined on a single application costfactor matrix.

Once at least one application cost factor matrix is identifiedcontaining the application attributes, 1 . . . n, which were received inaccordance with step 306, the application cost factors, ^(i)α₁ . . .^(i)α_(n), for each migration task in the assessment template areobtained from the application cost factor matrix or matrices. Note that^(i)α₁ . . . ^(i)α_(n)may differ for each migration task.

Another type of cost factor matrix that may be used in returning a TypeC assessment is an environment cost factor matrix. Each environment costfactor matrix sets forth factors, comprising the amounts by which thecosts of various migration tasks are changed due to at least oneenvironment attribute. An environment cost factor matrix may conformsubstantially to that shown in FIG. 8, wherein an environment costfactor, ^(i)ε_(p), is shown at the intersection of each row containing amigration task, ‘i’, and a column containing an environment attribute,‘p’. Note that an environment cost factor matrix may contain environmentcost factors for more migration tasks than are received in step 303.

The factors may comprise proportions by which the base costs ofmigration tasks may be multiplied to reflect the effect of environmentattributes in increasing, decreasing, or not affecting, the average basecosts of the migration tasks during a migration process. The effect ofeach environment attribute upon the base cost of each migration task,and hence the development of each environment cost factor, ^(i)ε_(p),will be readily appreciated by those skilled in the art.

A single universal environment cost factor matrix may be used, or manyenvironment cost factor matrices may be used, each one containingfactors for only one type of environment attribute, such as externalinterface, media, and the like. Species of environment attributes may beparticularized (such as 128-bit SSL security, hypertext transferprotocol usage, COBOL language and the like). Species of environmentattributes may be non-particularized (such as, standard languages,non-standard security, custom communication transfer protocols, and thelike). Particularized and non-particularized species may be combined ona single environment cost factor matrix.

Once at least one environment cost factor matrix is identifiedcontaining the environment attributes, 1 . . . p, which were received inaccordance with step 306, the environment cost factors, ^(i)ε₁ . . .^(i)ε_(p)), for each migration task in the assessment template areobtained from the environment cost factor matrix or matrices. Note that^(i)ε₁ . . . ^(i)ε_(p), may differ for each migration task.

Another type of cost factor matrix that may be used in returning a TypeC assessment is a testing cost factor matrix. Each testing cost factormatrix sets forth factors, comprising the amounts by which the costs ofvarious migration tasks are changed due to at least one testingattribute. A testing cost factor matrix may conform substantially tothat shown in FIG. 18, wherein a testing cost factor, ^(i)η_(r), isshown at the intersection of each row containing a migration task, ‘i’,and a column containing an environment attribute, ‘r’. Note that theeffects of testing attributes may only affect, for example, the baselinetesting and system testing costs. This example is shown in FIG. 18,where i=2 or 4, because these are the task numbers given to baseline andsystem testing in the example assessment template shown in FIG. 2.

The factors may comprise proportions by which the base cost of baselinetest and/or system test may be multiplied to reflect the effect of thetesting attribute in increasing, decreasing, or not affecting, theaverage base cost of the baseline testing and/or system testing during amigration process. The effect of each testing attribute upon the basecost of baseline testing and system testing, and hence the developmentof each environment cost factor, ^(i)η_(r) will be readily appreciatedby those skilled in the art.

A single universal testing cost factor matrix may be used, or manyenvironment cost factor matrices may be used, each one containingfactors for only one type of testing attribute, such as re-building theapplication, use of unit testing, creation of testing programs, testingsites, testing criteria and the like. Species of testing attributes maybe particularized (such as no re-building, progressive unit testing,perform baseline test off-site and the like). Species of testingattributes may be non-particularized (such as, standard testing suites,non-standard performance criteria, custom hardware simulation duringtesting, and the like). Particularized and non-particularized speciesmay be combined on a single testing cost factor matrix.

Once at least one testing cost factor matrix is identified containingthe testing attributes, 1 . . . r, which were received in accordancewith step 306, the testing cost factors, ^(i)η₁ . . . ^(i)η_(r), forbaseline and system testing are obtained from the testing cost factormatrix or matrices. Note that ^(i)η₁ . . . ^(i)η_(r), may differ foreach type of testing.

In accordance with step 308, the cost for the migration is estimated.The calculation of estimated cost is achieved by applying the costfactors assigned in step 307 to the base costs assigned in step 305. Thecost f(c_(i)) for each individual migration task received in step 303,other than baseline test and system test, is estimated as follows:

f(c _(i))=^(i)β^(i)λ_(S−T)(^(i) h ₁ ^(i) h ₂ . . . ^(i) h _(n))(^(i)ω₁^(i)ω₂ . . . ^(i)ω_(m))(^(i)α₁ ^(i)α₂ . . . ^(i)α_(n))(^(i)ε₁ ^(i)ε₂ . .. ^(i)ε_(p))

The cost f(c₂) for baseline test is estimated as follows:

f(c ₂)=²β²λ_(S−T)(² h ₁ ² h ₂ . . . ²h_(n))(²ω₁ ²ω₂ . . . ²ω_(m))(²α₁ ²₂ . . .²α_(n))(²ε₁ ²ε₂ . . . ²ε_(p))(²η₁ ²η₂ . . . ²η_(r)).

The cost f(c₂) for system test is estimated as follows:

f(c ₄)=⁴β⁴λ_(S−T)(⁴ h ₁ ⁴ h ₂ . . . ⁴h_(n))(⁴ω₁ ⁴ω₂ . . . ⁴ω_(m))(⁴α₁ ⁴₂ . . .⁴α_(n))(⁴ε₁ ⁴ε₂ . . . ⁴ε_(p))(⁴η₁ ⁴η₂ . . . ⁴η_(r)).

The cost estimate for the migration process shown on the assessmenttemplate is then estimated as follows:

$\sum\limits_{i = 1}^{i}{f\left( c_{i} \right)}$

Where time requirements are estimated, step 307 includes assignment oftime factors to each migration task. For a Type C assessment, theassignment of time factors is preferably achieved by a user choosingattributes from pre-defined lists. The attributes are then compared withat least one time factor matrix in a database. Each time factor matrixcontains time factors for various migration tasks, when at least oneattribute is relevant to migrating a specified application from aspecified source platform to a specified target platform. Each timefactor matrix may set forth factors for migration tasks, with respect tospecific applications. Alternatively, each time factor matrix may setforth time factors for migration tasks, with respect to the degree ofcommonality of various applications. For example, time factor matricesmay be built for standard applications (for example, word processors anddata storage), non-standard (such as compilers and communicationsoftware), and custom-made applications. Matrices may be built toreflect additional qualitative categories of applications that have aquantifiably distinguishable effect on the time requirement for at leastone migration task.

Various time factor matrices are described in further detail, below.

One example of a time factor matrix contemplated for returning a Type Cassessment is a complexity time factor matrix. Each complexity timefactor matrix sets forth factors, comprising the amounts by which thetime requirements for various migration tasks are changed by thecomplexity of migrating an application between a source platform and atarget platform. A complexity time factor matrix may conformsubstantially to that shown in FIG. 9B, wherein a complexity timefactor, ^(i)ψ_(S−T), is shown at the intersection of each row containinga migration task, ‘i’, and a column containing a source-targetcombination, ‘S-T’. Note that a complexity time factor matrix maycontain complexity cost factors for more migration tasks than arereceived in step 303.

The complexity time factors may comprise proportions by which the basetime requirements for migration tasks may be multiplied to reflect theeffect of the source-target combination in increasing, decreasing, ornot affecting, the average base time requirement for the migration tasksduring a migration process. The effect of each source-target combinationupon the base time requirement for each migration task, and hence thedevelopment of each complexity time factor, ^(i)ψ_(S−T), will be readilyappreciated by those skilled in the art.

A single universal complexity time factor matrix may be used, or manycomplexity time factor matrices may be used, each one containing factorsfor only one type of source-target combination, such as UNIX-UNIX;Generic UNIX-UNIX Variant; AIXv(x)-AIXv(x+1); Windows XP-Solaris/Intel;and the like. Species of source and target platforms may beparticularized (such as Bull GCOS, DG DG-UX, FreeBSD, HP HP-UX, HP MPE,HP NSK, HP OpenVMS/Alpha, HP OpenVMS/VAX, HP Tru64 UNIX, HP VMS/VAX, IBMAIX, IBM DOS/VSE, IBM DYNIX/ptx, IBM MVS, IBM OS/390, IBM zOS, IntelLinux, SCO UnixWare, SGI Irix, Solaris/Intel, Solaris/SPARC, Windows 9x,Windows NT/200, Windows XP and the like). Species of source and targetplatforms may be non-particularized (such as common platform, uncommonplatform, custom platform, proprietary platform, and the like).Particularized and non-particularized species may be combined on asingle complexity time factor matrix and in individual source-targetcombinations (such as WinXP-proprietary platform).

Once at least one complexity time factor matrix is identified thatreflects the source-target combination received in step 301, complexitytime factor, ^(i)ψ_(S−T), for each migration task in the assessmenttemplate is obtained from the complexity time factor matrix or matrices.Note that ^(i)ψ_(S−T) may differ for each migration task.

Another type of time factor matrix that may be used in returning a TypeC assessment is a hardware time factor matrix. Each hardware time factormatrix sets forth factors, comprising the amounts by which the timerequirements for various migration tasks are changed due to the presenceof at least one hardware attribute during migration. A hardware timefactor matrix may conform substantially to that shown in FIG. 10,wherein a hardware time factor, ^(i)H_(k), is shown at the intersectionof each row containing a migration task, ‘i’, and a column containing ahardware attribute combination, Note that a hardware time factor matrixmay contain hardware time factors for more migration tasks than arereceived in step 303.

The hardware time factors may comprise proportions by which the basetime requirements for migration tasks may be multiplied to reflect theeffect of the difference in the hardware attributes of the source andtarget platforms, in increasing, decreasing, or not affecting, theaverage base time requirement of the migration tasks during a migrationprocess. The effect of each hardware attribute combination upon the basetime requirement for each migration task, and hence the development ofeach hardware time factor, ^(i)H_(k), will be readily appreciated bythose skilled in the art.

A single universal hardware time factor matrix may be used, or manyhardware time factor matrices may be used, each one containing factorsfor only one type of hardware attribute combination, such as externalinterface combinations, media combinations, byte storage sequencingcombinations, and the like. Species of hardware attributes may beparticularized (such as big endian to little endian, and the like).Species of hardware attributes may be non-particularized (such as,standard connectivity to non-standard connectivity, common processors tocustom processors, and the like). Particularized and non-particularizedspecies may be combined on a single hardware time factor matrix.

Once at least one hardware time factor matrix is identified containingthe hardware attribute combinations, 1 . . . k, which were received inaccordance with step 306, the hardware time factors, ^(i)H₁ . . .^(i)H_(k), for each migration task in the assessment template areobtained from the hardware time factor matrix or matrices. Note that^(i)H₁ . . . ^(i)H_(k), may differ for each migration task.

Another type of time factor matrix that may be used in returning a TypeC assessment is an operating system (OS) time factor matrix. Each OStime factor matrix sets forth factors, comprising the amounts by whichthe time requirements for various migration tasks are changed due to theoperating system operated on the source platform (due to, for example,threads, embedded SQL/RDBMS access, kernel mode routines, clusteringfunctionality, operating system intrinsics, library functions, etc.). AnOS time factor matrix may conform substantially to that shown in FIG.11, wherein an OS time factor, ^(i)θ_(m), is shown at the intersectionof each row containing a migration task, ‘i’, and a column containing anoperating system, ‘m’. Note that an OS time factor matrix may contain OStime factors for more migration tasks than are received in step 303.

The OS time factors may comprise proportions by which the base timerequirements for migration tasks may be multiplied to reflect the effectof the dependence of the application upon the initial operatingsystem(s) (due to, for example, threads, embedded SQL/RDBMS access,kernel mode routines, clustering functionality, operating systemintrinsics, library functions, etc.) in increasing, decreasing, or notaffecting, the average base time requirements for the migration taskduring a migration process. The effect of each operating system upon thebase time requirement for each migration task, and hence the developmentof each OS time factor, ^(i)θ_(m), will be readily appreciated by thoseskilled in the art.

A single universal OS time factor matrix may be used, or many OS timefactor matrices may be used, each one containing factors for only onetype of operating system. Species of operating systems may beparticularized (such as Microsoft Windows® NT, Sun Solaris® and thelike). Species of operating systems may be non-particularized (such as,standard, non-standard, custom, and the like). Particularized andnon-particularized species may be combined on a single OS time factormatrix.

Once at least one OS time factor matrix is identified containing theoperating systems, 1 . . . m, which were received in accordance withstep 306, the OS time factors, ^(i)θ₁ . . . ^(i)θ_(m), for eachmigration task in the assessment template are obtained from the OS timefactor matrix or matrices. Note that ^(i)θ₁ . . . ^(i)θ_(m), may differfor each migration task.

Another type of time factor matrix that may be used in returning a TypeC assessment is an application time factor matrix. Each application timefactor matrix sets forth factors, comprising the amounts by which thetime requirements for various migration tasks are changed due to atleast one attribute of the application being migrated. An applicationtime factor matrix may conform substantially to that shown in FIG. 12,wherein an application time factor,

, is shown at the intersection of each row containing a migration task,and a column containing an application attribute, ‘n’. Note that anapplication time factor matrix may contain application time factors formore migration tasks than are received in step 303.

The application time factors may comprise proportions by which the basetimes of migration tasks may be multiplied to reflect the effect ofapplication attributes in increasing, decreasing, or not affecting, theaverage base times of the migration tasks during a migration process.The effect of each application attribute upon the base time requirementfor each migration task, and hence the development of each applicationtime factor,

, will be readily appreciated by those skilled in the art.

A single universal application time factor matrix may be used, or manyapplication time factor matrices may be used, each one for a singleapplication attribute, such as real-time operation, OLTP, and the like.Species of applications may be non-particularized (such as, standard,non-standard, custom, and the like). Particularized andnon-particularized species may be combined on a single application timefactor matrix.

Once at least one application time factor matrix is identifiedcontaining the application attributes, 1 . . . n, which were received inaccordance with step 306, the application time factors,

. . .

, for each migration task in the assessment template are obtained fromthe application time factor matrix or matrices. Note that

. . .

, may differ for each migration task.

Another type of time factor matrix that may be used in returning a TypeC assessment is an environment time factor matrix. Each environment timefactor matrix sets forth factors, comprising the amounts by which thetime requirements for various migration tasks are changed due to atleast one environment attribute. An environment time factor matrix mayconform substantially to that shown in FIG. 13, wherein a environmenttime factor, ^(i)χ_(p), is shown at the intersection of each rowcontaining a migration task, ‘i’, and a column containing an environmentattribute, ‘p’. Note that an environment time factor matrix may containenvironment time factors for more migration tasks than are received instep 303.

The factors may comprise proportions by which the base times ofmigration tasks may be multiplied to reflect the effect of environmentattributes in increasing, decreasing, or not affecting, the average basetimes of the migration tasks during a migration process. The effect ofeach environment attribute upon the base time requirement for eachmigration task, and hence the development of each environment timefactor, ^(i)χ_(p), will be readily appreciated by those skilled in theart.

A single universal environment time factor matrix may be used, or manyenvironment time factor matrices may be used, each one containingfactors for only one type of environment attribute, such as externalinterface, media, and the like. Species of environment attributes may beparticularized (such as 128-bit SSL security, hypertext transferprotocol usage, COBOL language and the like). Species of environmentattributes may be non-particularized (such as, standard languages,non-standard security, custom communication transfer protocols, and thelike). Particularized and non-particularized species may be combined ona single environment time factor matrix.

Once at least one environment time factor matrix is identifiedcontaining the environment attributes, 1 . . . p, which were received inaccordance with step 306, the environment time factors, ^(i)χ₁ . . .^(i)χ_(p), for each migration task in the assessment template areobtained from the environment time factor matrix or matrices. Note that^(i)χ₁ . . . ^(i)χ_(p), may differ for each migration task.

Another type of time factor matrix that may be used in returning a TypeC assessment is a testing time factor matrix. Each testing time factormatrix sets forth factors, comprising the amounts by which the times ofvarious migration tasks are changed due to at least one testingattribute. A testing time factor matrix may conform substantially tothat shown in FIG. 19, wherein a testing time factor, ^(i)b_(r), isshown at the intersection of each row containing a migration task, ‘i’,and a column containing a testing attribute, ‘r’. This example is shownin FIG. 19, where i=2 or 4, because these are the task numbers given tobaseline and system testing in the example assessment template shown inFIG. 2.

The factors may comprise proportions by which the base time of baselinetest and/or system test may be multiplied to reflect the effect of thetesting attribute in increasing, decreasing, or not affecting, theaverage base time of the baseline testing and/or system testing during amigration process. The effect of each testing attribute upon the basetime requirement for baseline testing and system testing, and hence thedevelopment of each testing time factor, ^(i)b_(r), will be readilyappreciated by those skilled in the art.

A single universal testing time factor matrix may be used, or manytesting time factor matrices may be used, each one containing factorsfor only one type of testing attribute, such as re-building theapplication, use of unit testing, creation of testing programs, testingsites, testing criteria and the like. Species of testing attributes maybe particularized (such as no re-building, progressive unit testing,perform baseline test off-site and the like). Species of testingattributes may be non-particularized (such as, standard testing suites,non-standard performance criteria, custom hardware simulation duringtesting, and the like). Particularized and non-particularized speciesmay be combined on a single testing time factor matrix.

Once at least one testing time factor matrix is identified containingthe testing attributes, 1 . . . r, which were received in accordancewith step 306, the testing time factors, ^(i)b₁ . . . ^(i)b_(r), forbaseline and system testing are obtained from the testing time factormatrix or matrices. Note that ^(i)b₁ . . . ^(i)b_(r), may differ foreach type of testing.

The time requirement for the migration is estimated, in accordance withstep 309,. The time requirement f(t_(i)) for each individual migrationtask shown on the assessment template, other than baseline test andsystem test, is then estimated as follows:

f(t _(i))=^(i) T ^(i)ψ_(S−T)(^(i) H ₁ ^(i) H ₂ . . . ^(i) H _(k))(^(i)θ₁^(i)θ₂ . . . ^(i)θ_(m))(^(i)

^(i)

. . . ^(i)

_(n))(^(i)χ₁ ^(i)χ . . . ^(i)χ_(p))

The time requirement for baseline test is estimated as follows:

f(t ₂)=² T ²ψ_(S−T)(² H ₁ ² H ₂ . . . ² H _(k))(²θ₁ ²θ₂ . . . ²θ_(m))(²

₁ ²

₂ . . . ²

_(n))(²χ₁ ²χ₂ . . . ²χ_(p))(² b ₁ . . . ² b _(r))

The time requirement for system test is estimated as follows:

f(t ₄)=⁴ T ⁴ψ_(S−T)(⁴ H ₁ ⁴ H ₂ . . . ⁴ H _(k))(⁴θ₁ ⁴θ₂ . . . ⁴θ_(m))(⁴

⁴

. . . ⁴

_(n))(⁴χ₁ ⁴χ₂ . . . ⁴χ_(p))(⁴ b ₁ . . . ⁴ b _(r))

The time estimate for the migration process shown on the assessmenttemplate is estimated as follows:

$\sum\limits_{i = 1}^{i}{f\left( t_{i} \right)}$

In accordance with step 310, desired tolerances may be applied in themanner described with reference to FIG. 1. In accordance with step 311,a Type C assessment is output (printed or displayed), which showsestimated costs and/or time requirements for the migration process andeach migration task in the assessment template, given the base variablesand attributes received. Any such estimates may be represented as fixednumbers or ranges. In the preferred embodiment of the invention, costsand/or time requirements estimated in a Type C assessment are output asranges.

FIG. 14 is a flow diagram illustrating a method for returning a Type Bassessment for the migration of an application from a source platform toa target platform, in accordance with the current invention. Inaccordance with step 1401, base variables are received, which comprisean application to be migrated, a source platform on which theapplication currently operates, and a target platform on which theapplication is to be re-hosted.

The application variable may comprise a specific application name andversion. Alternatively, the application may include the function of theapplication and (if more than one function) its component parts, such asproduction control, batch processing, data mining, online transactionprocessing (OLTP), or other functions. In the preferred embodiment ofthe invention, the application variable comprises the name, version andfunction(s) of the application and its component parts.

The source and target platform variables may comprise any platformssuitable for operating the application that is to be migrated. Theseplatforms may include, for example, UNIX (generic or variants), OpenVMS,IBM AS/400 or iSeries, HP 300 MPE, IBM Mainframe, and other platformsthat are readily known to those skilled in the art.

In accordance with step 1402, a user's choice of a Type B assessment isreceived. In accordance with step 1403, an identifier for at least onemigration task is received, as described with reference to FIG. 1. Inaccordance with step 1404, an assessment template may be created in themariner described with reference to FIG. 1. The assessment template fora Type B assessment preferably comprises a representation of migrationtasks, which is not as high-level as a Type C assessment template butnot as detailed as a Type A assessment template.

In accordance with step 1405, base costs and/or times are assigned toeach migration task. For a Type B assessment, the base variables arepreferably compared with at least one base cost matrix in a database.Each base cost matrix sets forth an average base cost for migrationtasks, such as those listed previously. A base cost matrix may conformsubstantially to that shown in FIG. 4A, wherein migration tasks arelisted in one column, and a base cost is shown in the row containing amigration task to which the base cost corresponds. A base cost , ^(i)β,is extracted from the database, for each migration task, ‘i’, receivedin step 1403. Note that each base cost matrix may contain base cost datafor more migration tasks than are received in step 1403.

Each base cost matrix may set forth average costs for migration tasks,with respect to specific applications. Alternatively, each base costmatrix may set forth average base costs for migration tasks, withrespect to the degree of commonality of various applications. Forexample, base cost matrices may be built for standard applications (forexample, word processors and data storage), non-standard (such ascompilers and communication software), and custom-made applications.Matrices may be built to reflect additional qualitative categories ofapplications that have a quantifiably distinguishable effect on the costof at least one migration task.

Where time requirements are being estimated, base time requirements areassigned to each migration task. For a Type B assessment, the basevariables are preferably compared with at least one base time matrix ina database. Each base cost matrix sets forth an average base cost formigration tasks, such as those listed previously. A base timerequirement matrix may conform substantially to that shown in FIG. 9A,wherein migration tasks are listed in one column, and a base timerequirement is shown in the row containing a migration task to which thebase time requirement corresponds. A base time, ^(i)T, is extracted fromthe database, for each migration task, ‘i’, received in step 1403. Notethat each base cost matrix may contain base time data for more migrationtasks than are received in step 1403.

Each base time requirement matrix may set forth average timerequirements for migration tasks, with respect to specific applications.Alternatively, each base time matrix may set forth average base timerequirements for migration tasks, with respect to the degree ofcommonality of various applications. For example, base time matrices maybe built for standard applications (for example, word processors anddata storage), non-standard (such as compilers and communicationsoftware), and custom-made applications. Matrices may be built toreflect additional qualitative categories of applications that have aquantifiably distinguishable effect on the time requirement for at leastone migration task.

In accordance with step 1406, at least one additional attribute isreceived. The migration attributes may comprise, for example, hardwareattributes, current operating system attributes, attributes of theapplication to be migrated, environment attributes, or testingattributes, as these are described with reference to FIG. 3, above.

In addition to the attributes described above, code metrics are alsoreceived, in accordance with 1407. Code metrics may comprise thoseattributes of the source code of the application being migrated, asthose are described with reference to FIG. 1, above. Code metrics areseparated into two categories: qualitative and numeric. Qualitative codemetrics include such parameters as structural integrity of theapplication, whether lexical functions are used, the degree to which theapplication is dependent upon its current operating system, and othercode metrics that are not intended to express an actual quantity (eventhough degrees of a qualitative code metric may be identified byrepresentative numbers). Numeric code metrics include such parameters ascode line inventories, code module inventories, file inventories, calland call type inventories, data volume, and other measurable quantitiesof source code attributes. Code metrics are described further withreference to assignment of factors in step 1408, below.

Code metrics may be received directly from a user. Alternatively, thesource code may be received and analyzed using a suitable utilityprogram for analyzing application source code and returning metrics suchas those described herein. The source code may be received via remoteelectronic transmission to a computing device—via ftp or e-mail, forexample—or physical delivery of computer-readable media followed byentry onto a computer system. In one embodiment, the source code isdelivered on computer-readable media and then disposed onto a servercomputer, desktop computer, laptop computer, or other computing devicesuitable for assessing the source code. In another embodiment, the codemay be transmitted via e-mail or ftp to an assessment server or othercomputing device suitable for analyzing the source code.

The metric utility may comprise any computer-implemented utilitysuitable for analyzing application source code and returning codemetrics, such as line counts, per type of code; keyword inventories,whether by individual keyword or categories of keywords, such asprocedural keywords, data keywords, environment keywords, identificationkeywords and the like; inventories of files and directory types, such assource code files, copybook files, COM files and the like; or lexicalfunctions; structural integrity; data volume; operating systemdependencies; calls and call types to keywords or lexical functions; andother measurable properties of source code that may impact upon the timeand cost for migrating an application from a source platform to a targetplatform.

In accordance with step 1408, cost and/or time factors corresponding toeach attribute received in step 1406, and corresponding to the basevariables, are assigned to each migration task received in step 1403.For a Type B assessment, cost factors corresponding to complexity,operating system attributes, hardware attributes, applicationattributes, environment attributes, and testing attributes, are assignedusing matrices, in the manners described with reference to FIG. 3.

Additionally, cost factors corresponding to code metrics received instep 1407 are also assigned to the migration tasks received in step1403. Qualitative code metrics obtained are compared with at least onecode cost factor matrix. Each code cost factor matrix sets forthfactors, comprising the amounts by which the costs of various migrationtasks are changed due to the presence of at least one qualitativeattribute in the source code of the application to be re-hosted. A codecost factor matrix may conform substantially to that shown in FIG. 15,wherein a qualitative code cost factor ^(i)κ_(q) is shown at theintersection of each row containing a migration task, ‘i’, and a columncontaining a qualitative code metric, ‘q’. Note that a code cost factormatrix may contain code cost factors for more migration tasks than arereceived in step 1403.

The qualitative code cost factors may comprise proportions by which thebase cost of migration tasks may be multiplied to reflect the effect ofthe qualitative code metric in increasing, decreasing, or not affecting,the average base cost for the migration tasks during the migrationprocess. The effect of each qualitative code metric upon the averagebase cost for each migration task, and hence the development of eachqualitative code cost factor, ^(i)κ_(q), will be readily appreciated bythose skilled in the art.

A single universal code cost factor matrix may be used, or many codecost factor matrices may be used, each one containing only one type ofqualitative code metric. Qualitative code metrics may be expressed indual form (such as, structural integrity=YES; operating systemdependent=NO; lexical functions=YES). Alternatively, qualitative codemetrics may be categorized by degree (such as, low structural integrity;negligible dependence upon operating system; high use of lexicalfunctions). Dual and categorized qualitative code metric representationsmay be combined on a single code cost factor matrix.

Once at least one code cost factor matrix is identified containing thequalitative code metrics, 1 . . . q, which were received in accordancewith step 1407, the qualitative code cost factors, ^(i)κ₁ . . .^(i)κ_(q), for each migration task in the assessment template areobtained from the code cost factor matrix or matrices. Note that ^(i)κ₁. . . ^(i)κ_(q) may differ for each migration task.

Because an actual quantity is returned for numeric code metrics, theeffect of a numeric code metric, ‘s’, on the cost of a migration task,‘i’, may be accounted for formulaically. As the value returned for themetric (such as number of code lines) increases or decreases, then anumeric code cost factor, ^(i)φ_(s), may simply be calculated by anappropriate function, or a group of functions that differ for each typeof numeric code metric, 1 . . . s. The functions used to calculate eachnumeric code cost factor, ^(i)φ₃, may have linear elements, geometricelements, differential elements, or any combination of the three.Additionally, the functions may reflect benchmarks, wherein a numericcode cost factor remains constant over a range of values for the numericcode metric. The effect of each numeric code metric upon the averagebase cost for each migration task, and hence the formulae forcalculating each numeric code cost factor, ^(i)φ₃, will be readilyappreciated by those skilled in the art.

Once factors for each numeric code metric, 1 . . . s, which werereceived in accordance with step 1407, are calculated for each migrationtask ‘i’, then a set of numeric code cost factors, ^(i)φ₁ . . .^(i)φ_(s), is obtained for each migration task. Note that the numericcode cost factors ^(i)φ₁ . . . ^(i)φ_(s) may differ for each migrationtask.

In accordance with step 1409, the estimated cost f(c_(i)) for eachmigration task in the assessment template is calculated. The calculationof estimated cost is achieved by applying the cost factors assigned instep 1408 to the base costs assigned in step 1405. Integrating thefactors assigned for the code metrics received in step 1407, with theequations described with reference to FIG. 3, the cost f(c_(i)) for eachindividual migration task received in step 1403, other than baselinetest and system test, is then estimated as follows:

f(c _(i))=^(i)β^(i)λ_(S−T)(^(i h) ₁ ^(i) h ₂ . . . ^(i) h _(n))(^(i)ω₁^(i)ω₂ . . . ^(i)ω_(m))(^(i)α₁ ¹α₂ . . . ^(i)α_(n))(^(i)ε₁ ^(i)ε₂ . . .^(i)ε_(p))(^(i)κ₁ ^(i)κ₂ . . . ^(i)κ_(q))(^(i)φ₁ ^(i)φ₂ . . . ^(i)φ_(s))

The cost f(c₂) for baseline test is estimated as follows:

f(c ₂)=²β²λ_(S−T)(² h ₁ ² h ₂ . . . ² h _(n))(²ω₁ ²ω₂ . . . ²ω_(m))(²α₁²α₂ . . . ²α_(n))(²ε₁ ²ε₂ . . . ²ε_(p))(²κ₁ ²κ₂ . . . ²κ_(q))(²φ₁ ²φ₂ .. . ²φ_(s))(²η₁ . . . ²η_(r)).

The cost f(c₄) for system test is estimated as follows:

f(c ₄)=⁴β⁴λ_(S−T)(⁴ h ₁ ⁴ h ₂ . . . ⁴ h _(n))(⁴ω₁ ⁴ω₂ . . . ⁴ω_(m))(⁴α₁⁴α₂ . . . ⁴α_(n))(⁴ε₁ ⁴ε₂ . . . ⁴ε_(p))(⁴κ₁ ⁴κ₂ . . . ⁴κ_(q))(⁴φ₁ ⁴φ₂ .. . ⁴φ_(s))(⁴η₁ . . . ⁴η_(r)).

The cost estimate for the migration process shown on the assessmenttemplate is estimated as follows:

$\sum\limits_{i = 1}^{i}{f\left( c_{i} \right)}$

Where time requirements are estimated, step 1408 includes assignment oftime factors to each migration task. For a Type B assessment, timefactors corresponding to complexity, operating system attributes,hardware attributes, application attributes, environment attributes, andtesting attributes, are assigned using matrices, in the mannersdescribed with reference to FIG. 3.

Additionally, time factors corresponding to code metrics received instep 1407 are also assigned to the migration tasks received in step1403. Qualitative code metrics are compared with at least one code timefactor matrix. Each code time factor matrix sets forth factors,comprising the amounts by which the time requirements of variousmigration tasks are changed due to the presence of at least onequalitative attribute in the source code of the application to bere-hosted. A code time factor matrix may conform substantially to thatshown in FIG. 17, wherein a qualitative code time factor, ^(i)μ_(q), isshown at the intersection of each row containing a migration task, ‘i’,and a column containing a specie of qualitative code metric, ‘q’. Notethat a code time factor matrix may contain code time factors for moremigration tasks than are received in step 1403.

The qualitative code time factors may comprise proportions by which thebase time requirements for migration tasks may be multiplied to reflectthe effect of the qualitative code metric in increasing, decreasing, ornot affecting, the average base time requirement for the migration tasksduring the migration process. The effect of each qualitative code metricupon the average base time requirement for each migration task, andhence the development of each qualitative code time factor, ^(i)μ_(q),will be readily appreciated by those skilled in the art.

A single universal code time factor matrix may be used, or many codetime factor matrices may be used, each one containing only one type ofqualitative code metric. Qualitative code metrics may be expressed indual form (such as, structural integrity=YES; operating systemdependent=NO; lexical functions=YES). Alternatively, species ofqualitative code metrics may be categorized by degree (such as, lowstructural integrity; negligible dependence upon operating system; highuse of lexical functions). Dual and categorized qualitative code metricrepresentations may be combined on a single code time factor matrix.

Once at least one code time factor matrix is identified containing thequalitative code metrics, 1 . . . q, which were returned in accordancewith step 1407, the qualitative code time factors, ^(i)μ₁ . . .^(i)μ_(q), for each migration task in the assessment template areobtained from the code time factor matrix or matrices. Note that maydiffer for each migration task.

Because an actual quantity is returned for numeric code metrics, theeffect of a numeric code metric, ‘s’, on the time requirement for amigration task, may be accounted for formulaically. As the valuereturned for the metric (such as number of code lines) increases ordecreases, then a numeric code time factor, ^(i)v_(s), may simply becalculated by an appropriate function, or a group of functions thatdiffer for each type of numeric code metric, 1 . . . s. The functionsused to calculate each numeric code time factor, ^(i)v_(s), may havelinear elements, geometric elements, differential elements, or anycombination of the three. Additionally, the functions may reflectbenchmarks, wherein a numeric code time factor remains constant over arange of values for the numeric code metric. The effect of each numericcode metric upon the average base time requirement for each migrationtask, and hence the formulae for calculating each numeric code timefactor, ^(i)v_(s), will be readily appreciated by those skilled in theart.

Once factors for each numeric code metric, 1 . . . s, which werereturned in accordance with step 1409, are calculated for each migrationtask ‘i’, then a set of numeric code time factors, ^(i)v₁ . . .^(i)v_(s), is obtained for each migration task. Note that ^(i)v₁ . . .^(i)v_(s) may differ for each migration task.

In accordance with step 1410, the time requirement for the migration isestimated. The calculation of estimated time is achieved by applying thetime factors assigned in step 1408 to the base costs assigned in step1405. Integrating the time factors assigned for the code metricsreceived in step 1407, with the equations described with reference toFIG. 3, the time requirement f(t_(i)) for each individual migration taskshown on the assessment template, other than baseline test and systemtest, is estimated as follows:

f(t _(i))=^(i) T ^(i)ψ_(S−T)(^(i) H ₁ ^(i) H ₂ . . . ^(i) H _(k))(^(i)θ₁^(i)θ₂ . . . ^(i)θ_(m))(^(i)

₁ ^(i)

₂ . . . ^(i)

_(n))(^(i)χ₁ ^(i)χ₂ . . . ^(i)χ_(p))(^(i)μ₁ ^(i)μ₂ . . . ^(i)μ_(q))(^(i)v ₁ ^(i) v ₂ . . . ^(i) v _(s))

The time requirement for baseline test is estimated as follows:

f(t ₂)=² T ²ψ_(S−T)(² H ₁ ² H ₂ . . . ² H _(k))(²θ₁ ²θ₂ . . . ²θ_(m))(²

²

. . . ²

_(n))(²χ₁ ²χ₂ . . . ²χ_(p))(²μ₁ ²μ₂ . . . ²μ_(q))(² v ₁ ² v ₂ . . . ² v_(s))(² b ₁ . . . ² b _(r))

The time requirement for system test is estimated as follows:

f(t ₄)=⁴ T ⁴ψ_(S−T)(⁴ H ₁ ⁴ H ₂ . . . ⁴ H _(k))(⁴θ₁ ⁴θ₂ . . . ⁴θ_(m))(⁴

₁ ⁴

₂ . . . ⁴

_(n))(⁴χ₁ ⁴χ₂ . . . ⁴χ_(p))(⁴μ₁ ⁴μ₂ . . . ⁴μ_(q))(⁴ v ₁ ⁴ v ₂ . . . ⁴ v_(s))(⁴ b ₁ . . . ⁴ b _(r))

The time estimate for the migration process shown on the assessmenttemplate is estimated as follows:

$\sum\limits_{i = 1}^{i}{f\left( t_{i} \right)}$

In accordance with step 1411, desired tolerances are applied in themanner described with reference to FIG. 1. In accordance with step 1412,a Type B assessment is output (printed or displayed), which showsestimated costs and/or time requirements for the migration process andeach migration task in the assessment template, given the basevariables, attributes and code metrics received. Any such estimates maybe represented as fixed numbers or ranges. In the preferred embodimentof the invention, costs and/or time requirements estimated in a Type Bassessment are output as ranges.

FIG. 16 is a flow diagram illustrating a method for returning a Type Aassessment for the migration of an application from a source platform toa target platform, in accordance with the current invention. Inaccordance with step 1601, base variables are received, which comprisean application to be migrated, a source platform on which theapplication currently operates, and a target platform on which theapplication is to be re-hosted.

The application variable may comprise a specific application name andversion. Alternatively, the application may include the function of theapplication and (if more than one function) its component parts, such asproduction control, batch processing, data mining, online transactionprocessing (OLTP), or other functions. In the preferred embodiment ofthe invention, the application variable comprises the name, version andfunction(s) of the application and its component parts.

The source and target platform variables may comprise any platformssuitable for operating the computer-based application to be migrated.These platforms may include, for example, UNIX (generic or variants),OpenVMS, IBM AS/400 or iSeries, HP 300 MPE, IBM Mainframe, and otherplatforms that are readily known to those skilled in the art.

In accordance with step 1602, a user's choice of a Type B assessment isreceived. In accordance with step 1603, an identifier for at least onemigration task is received, as described with reference to FIG. 1. Inaccordance with step 1604, an assessment template may be created in themanner described with reference to FIG. 1. The assessment templateshould contain both high-level tasks and the low-level tasks associatedwith each, such that cost and time requirements will be estimated ingreat detail, when compared to a Type C or Type B assessment.

In accordance with step 1605, base costs and/or times are assigned toeach migration task. For a Type A assessment, the base variables arepreferably compared with at least one base cost matrix in a database.Each base cost matrix sets forth an average base cost for migrationtasks, such as those listed previously. A base cost matrix may conformsubstantially to that shown in FIG. 4A, wherein migration tasks arelisted in one column, and a base cost is shown in the row containing amigration task to which the base cost corresponds. A base cost , ^(i)β,is extracted from the database, for each migration task, ‘i’, receivedin step 1603. Note that each base cost matrix may contain base cost datafor more migration tasks than are received in step 1603.

Each base cost matrix may set forth average costs for migration tasks,with respect to specific applications. Alternatively, each base costmatrix may set forth average base costs for migration tasks, withrespect to the degree of commonality of various applications. Forexample, base cost matrices may be built for standard applications (forexample, word processors and data storage), non-standard (such ascompilers and communication software), and custom-made applications.Matrices may be built to reflect additional qualitative categories ofapplications that have a quantifiably distinguishable effect on the costof at least one migration task.

Where time requirements are being estimated, base time requirements areassigned to each migration task. For a Type A assessment, the basevariables are preferably compared with at least one base time matrix ina database. Each base cost matrix sets forth an average base cost formigration tasks, such as those listed previously. A base timerequirement matrix may conform substantially to that shown in FIG. 9A,wherein migration tasks are listed in one column, and a base timerequirement is shown in the row containing a migration task to which thebase time requirement corresponds. A base time, ^(i)T, is extracted fromthe database, for each migration task, ‘i’, received in step 1603. Notethat each base cost matrix may contain base time data for more migrationtasks than are received in step 1603.

Each base time requirement matrix may set forth average timerequirements for migration tasks, with respect to specific applications.Alternatively, each base time matrix may set forth average base timerequirements for migration tasks, with respect to the degree ofcommonality of various applications. For example, base time matrices maybe built for standard applications (for example, word processors anddata storage), non-standard (such as compilers and communicationsoftware), and custom-made applications. Matrices may be built toreflect additional qualitative categories of applications that have aquantifiably distinguishable effect on the time requirement for at leastone migration task.

In accordance with step 1606, at least one migration attribute isreceived. The migration attributes may comprise, for example, hardwareattributes, current operating system attributes, attributes of theapplication to be migrated, environment attributes, or testingattributes, as these are described with reference to FIG. 3, above. Toachieve the level of detail required for a Type A assessment to bedistinguishable from a Type B assessment, however, additional attributesmay need to be considered.

For a Type A assessment, additional hardware attributes are receivedthat will enable a more accurate cost analysis and plan. Such additionalhardware attributes may include, for example, whether the applicationoperates on multiple systems; user connection types (dial-up, serial,WAN, LAN, etc.); and the existence and currency of hardware architecturedocumentation.

For a Type A assessment, additional application attributes are receivedthat will enable a more accurate cost analysis and plan. Such additionalapplication attributes may include, for example, unique portingcomplexities; and whether previous unsuccessful portings have beenattempted. Such additional application attributes may also include theexistence and currency of application documentation, such asdocumentation for system and functional requirements; applicationarchitecture diagrams; subsystem top-level diagrams; module hierarchicaldiagrams; user documentation; Y2K documentation; and programmingstandards documentation.

For a Type A assessment, additional environment attributes are receivedthat will enable a more accurate cost analysis and plan. Such additionalenvironment attributes may include, for example, how the application ispartitioned (client/server, multi-threaded, one large module, discretemodules executable via CALL or ECTL); embedded SQL or DL/I access; andwhether the application is X/Open XA compliant.

Such additional environment attributes may also include, for example,configuration management tools on the source platform (e.g., Panvalet,Librarian); preferred configuration management tools on the targetplatform; the last re-building of the application; executable images inthe application; and whether the application links with non-standardobject libraries.

Such additional environment attributes may also include operating systemdependencies, such as multinational character sets; user-written ISPFpanels; inter-process communication; SYSPLEX functionality; MACRO calls;CSP map usage; internal EBCDIC coding dependencies; and other suchdependencies.

Such additional environment attributes may also include data storage andaccess attributes other than type, size and configuration of databasesand tables, such as needs to access archived data after migration;timing constraints for cutover; whether data can be accessed on mediaother than disks; import/export data from/to outside systems; type andsize of native files; whether native language I/O are used to accessnative data files; and whether the application shares data sets withother systems.

Such additional environment attributes may also include third partyproducts used to implement or augment any of the environment attributesdescribed herein.

In accordance with step 1607, the source code of the application to bemigrated is received. The source code may be received via remoteelectronic transmission to a computing device—via ftp or e-mail, forexample—or physical delivery of computer-readable media followed byentry onto a computer system. In one embodiment, the source code isdelivered on computer-readable media and then disposed onto a servercomputer, desktop computer, laptop computer, or other computing devicesuitable for assessing the source code. In another embodiment, the codemay be transmitted via e-mail or ftp to an assessment server or othercomputing device suitable for analyzing the source code.

In accordance with step 1608, metrics are returned for the source codereceived in step 1607. This may be accomplished by analyzing the sourcecode using a metric utility. The code metrics to be returned may bedefined prior to or after analysis of the source code, and may includequalitative and/or numeric code metrics, such as those describedpreviously. The metric utility may comprise any computer-implementedutility suitable for analyzing application source code and returningcode metrics, such as line counts, per type of code; keywordinventories, whether by individual keyword or categories of keywords,such as procedural keywords, data keywords, environment keywords,identification keywords and the like; inventories of files and directorytypes, such as source code files, copybook files, COM files and thelike; or lexical functions; structural integrity; data volume; operatingsystem dependencies; calls and call types to keywords or lexicalfunctions; and other measurable properties of source code that mayimpact upon the time and cost for migrating an application from a sourceplatform to a target platform.

In accordance with step 1609, cost and/or time factors corresponding toeach attribute received in step 1606, and corresponding to the basevariables, are assigned to each migration task received in step 1603.For a Type A assessment, cost factors corresponding to complexity,operating system attributes, hardware attributes, applicationattributes, environment attributes, and testing attributes, are assignedusing matrices, in the manners described with reference to FIG. 3.

Additionally, cost factors corresponding to code metrics received instep 1608 are also assigned to the migration tasks received in step1603. Qualitative code metrics obtained are compared with at least onecode cost factor matrix. Each code cost factor matrix sets forthfactors, comprising the amounts by which the costs of various migrationtasks are changed due to the presence of at least one qualitativeattribute in the source code of the application to be re-hosted. A codecost factor matrix may conform substantially to that shown in FIG. 15,wherein a qualitative code cost factor ^(i)κ_(q) is shown at theintersection of each row containing a migration task, ‘i’, and a columncontaining a qualitative code metric, ‘q’. Note that a code cost factormatrix may contain code cost factors for more migration tasks than arereceived in step 1603.

The qualitative code cost factors may comprise proportions by which thebase cost of migration tasks may be multiplied to reflect the effect ofthe qualitative code metric in increasing, decreasing, or not affecting,the average base cost for the migration tasks during the migrationprocess. The effect of each qualitative code metric upon the averagebase cost for each migration task, and hence the development of eachqualitative code cost factor, ^(i)κ_(q), will be readily appreciated bythose skilled in the art.

A single universal code cost factor matrix may be used, or many codecost factor matrices may be used, each one containing only one type ofqualitative code metric. Qualitative code metrics may be expressed indual form (such as, structural integrity=YES; operating systemdependent=NO; lexical functions=YES). Alternatively, qualitative codemetrics may be categorized by degree (such as, low structural integrity;negligible dependence upon operating system; high use of lexicalfunctions). Dual and categorized qualitative code metric representationsmay be combined on a single code cost factor matrix.

Once at least one code cost factor matrix is identified containing thequalitative code metrics, 1 . . . q, which were received in accordancewith step 1608, the qualitative code cost factors, , for each migrationtask in the assessment template are obtained from the code cost factormatrix or matrices. Note that ^(i)κ₁ . . . ^(i)κ_(q) may differ for eachmigration task.

Because an actual quantity is returned for numeric code metrics, theeffect of a numeric code metric, ‘s’, on the cost of a migration task,‘i’, may be accounted for formulaically. As the value returned for themetric (such as number of code lines) increases or decreases, then anumeric code cost factor, ^(i)φ_(s), may simply be calculated by anappropriate function, or a group of functions that differ for each typeof numeric code metric, 1 . . . s. The functions used to calculate eachnumeric code cost factor, ^(i)φ_(s), may have linear elements, geometricelements, differential elements, or any combination of the three.Additionally, the functions may reflect benchmarks, wherein a numericcode cost factor remains constant over a range of values for the numericcode metric. The effect of each numeric code metric upon the averagebase cost for each migration task, and hence the formulae forcalculating each numeric code cost factor, ^(i)φ_(s), will be readilyappreciated by those skilled in the art.

Once factors for each numeric code metric, 1 . . . s, which werereceived in accordance with step 1608, are calculated for each migrationtask ‘i’, then a set of numeric code cost factors, ^(i)φ₁ . . .^(i)φ_(s), is obtained for each migration task. Note that the numericcode cost factors ^(i)φ₁ . . . ^(i)φ_(s) may differ for each migrationtask.

In accordance with step 1610, a plurality of customized cost factors^(i)γ₁ . . . ^(i)γ_(t) are received from a user for at least onemigration task, ‘i’, and at least one additional attribute, ‘t’.Customized cost factors may be received from a user, in relation to theattributes described with reference to step 1606, or the code metricsreturned in step 1608, in place of any factors obtained using thematrices or calculations described herein. The customized cost factorsmay also relate to attributes not contained in such matrices, which theuser desires to include in cost estimation. The customized cost factors,^(i)γ₁ . . . ^(i)γ_(t), may be received in list form, or they may befilled in on a matrix template or multiple matrix templates, for storageand later reference.

Customized cost factors may comprise proportions by which the base costof migration tasks may be multiplied to reflect the effect of additionalattributes in increasing, decreasing, or not affecting, the average basecost of the migration tasks during a migration process. The effect ofeach additional attribute upon the base cost of each migration task, andhence the development of each customized cost factor, ^(i)γ_(t), will bereadily appreciated by those skilled in the art. Note that ^(i)γ₁ . . .^(i)γ_(t) may differ for each migration task.

In accordance with step 1611, the estimated cost f(c_(i)) for eachmigration task in the assessment template is calculated. The calculationof estimated cost is achieved by applying the cost factors assigned instep 1609 and the custom factors received in 1610 to the base costsassigned in step 1605. Integrating the factors assigned for the codemetrics received in step 1609, and the custom cost factors received instep 1610, with the equations described with reference to FIG. 3, thecost f(c_(i)) for each individual migration task received in step 1603,other than baseline test and system test, is estimated as follows:

f(c _(i))=^(i)β^(i)λ_(S−T)(^(i) h ₁ ^(i) h ₂ . . . ^(i) h _(n))(^(i)ω₁^(i)ω₂ . . . ^(i)ω_(m))(^(i)α₁ ^(i)α₂ . . . ^(i)α_(n))(^(i)ε₁ ^(i)ε₂ . .. ^(i)ε_(p))(^(i)κ₁ ^(i)κ₂ . . . ^(i)κ_(q))(^(i)φ₁ ^(i)φ₂ . . .^(i)φ_(s))(^(i)γ₁ ^(i)γ₂ . . . ^(i)γ_(t))

The cost f(c₂) for baseline test is estimated as follows:

f(c ₂)=²β²λ_(S−T)(² h ₁ ² h ₂ . . . ² h _(n))(²ω₁ ²ω₂ . . . ²ω_(m))(²α₁²α₂ . . . ²α_(n))(²ε₁ ²ε₂ . . . ²ε_(p))(²κ₁ ²κ₂ . . . ²κ_(q))(²φ₁ ²φ₂ .. . ²φ_(s))(²γ₁ ²γ₂ . . . ^(i)γ_(t))(²η₁ . . . ²η_(r)).

The cost f(c₄) for system test is estimated as follows:

f(c ₄)=⁴β⁴λ_(S−T)(⁴ h ₁ ⁴ h ₂ . . . ⁴ h _(n))(⁴ω₁ ⁴ω₂ . . . ⁴ω_(m))(⁴α₁⁴α₂ . . . ⁴α_(n))(⁴ε₁ ⁴ε₂ . . . ⁴ε_(p))(⁴κ₁ ⁴κ₂ . . . ⁴κ_(q))(⁴φ₁ ⁴φ₂ .. . ⁴φ_(s))(⁴γ₁ ⁴γ₂ . . . ⁴γ_(t))(⁴η₁ . . . ⁴η_(r)).

The cost estimate for the migration process shown on the assessmenttemplate is estimated as follows:

$\sum\limits_{i = 1}^{i}{f\left( c_{i} \right)}$

Where time requirements are estimated, step 1609 includes assignment oftime factors to each migration task. For a Type A assessment, timefactors corresponding to complexity, operating system attributes,hardware attributes, application attributes, environment attributes, andtesting attributes, are assigned using matrices, in the mannersdescribed with reference to FIG. 3.

Additionally, time factors corresponding to code metrics returned instep 1608 are also assigned to the migration tasks received in step1603. Qualitative code metrics are compared with at least one code timefactor matrix. Each code time factor matrix sets forth factors,comprising the amounts by which the time requirements of variousmigration tasks are changed due to the presence of at least onequalitative attribute in the source code of the application to bere-hosted. A code time factor matrix may conform substantially to thatshown in FIG. 17, wherein a qualitative code time factor, ^(i)μ_(q), isshown at the intersection of each row containing a migration task, ‘i’,and a column containing a specie of qualitative code metric, ‘q’. Notethat a code time factor matrix may contain code time factors for moremigration tasks than are received in step 1603.

The qualitative code time factors may comprise proportions by which thebase time requirements for migration tasks may be multiplied to reflectthe effect of the qualitative code metric in increasing, decreasing, ornot affecting, the average base time requirement for the migration tasksduring the migration process. The effect of each qualitative code metricupon the average base time requirement for each migration task, andhence the development of each qualitative code time factor, ^(i)μ_(q),will be readily appreciated by those skilled in the art.

A single universal code time factor matrix may be used, or many codetime factor matrices may be used, each one containing only one type ofqualitative code metric. Qualitative code metrics may be expressed indual form (such as, structural integrity=YES; operating systemdependent=NO; lexical functions=YES). Alternatively, species ofqualitative code metrics may be categorized by degree (such as, lowstructural integrity; negligible dependence upon operating system; highuse of lexical functions). Dual and categorized qualitative code metricrepresentations may be combined on a single code time factor matrix.

Once at least one code time factor matrix is identified containing thequalitative code metrics, 1 . . . q, which were returned in accordancewith step 1608, the qualitative code time factors, ^(i)μ₁ . . .^(i)μ_(q), for each migration task in the assessment template areobtained from the code time factor matrix or matrices. Note that ^(i)μ₁. . . ^(i)μ_(q) may differ for each migration task.

Because an actual quantity is returned for numeric code metrics, theeffect of a numeric code metric, ‘s’, on the time requirement for amigration task, ‘i’, may be accounted for formulaically. As the valuereturned for the metric (such as number of code lines) increases ordecreases, then a numeric code time factor, ^(i)v_(s), may simply becalculated by an appropriate function, or a group of functions thatdiffer for each type of numeric code metric, 1 . . . s. The functionsused to calculate each numeric code time factor, ^(i)v_(s), may havelinear elements, geometric elements, differential elements, or anycombination of the three. Additionally, the functions may reflectbenchmarks, wherein a numeric code time factor remains constant over arange of values for the numeric code metric. The effect of each numericcode metric upon the average base time requirement for each migrationtask, and hence the formulae for calculating each numeric code timefactor, ^(i)v_(s), will be readily appreciated by those skilled in theart.

Once factors for each numeric code metric, 1 . . . s, which werereturned in accordance with step 1608, are calculated for each migrationtask ‘i’, then a set of numeric code time factors, ^(i)v₁ . . .^(i)v_(s), is obtained for each migration task. Note that ^(i)v₁ . . .^(i)v_(s) may differ for each migration task.

Also, where time requirements are estimated, a plurality of customizedtime factors, ^(i)σ₁ . . . ^(i)σ_(t), may be received from a user, inaccordance with step 1610, for at least one migration task, ‘i’, and atleast one additional attribute, ‘t’. Customized time factors may bereceived from a user, in relation to the attributes described withreference to step 1606, or the code metrics returned in step 1608, inplace of any factors obtained using the matrices or calculationsdescribed herein. The customized time factors may also relate toattributes not contained in such matrices, which the user desires toinclude in estimation of time requirements. The customized time factors,^(i)σ₁ . . . ^(i)σ_(t), may be received in list form, or they may befilled in on a matrix template or multiple matrix templates, for storageand later reference.

Customized time factors may comprise proportions by which the base timeof migration tasks may be multiplied to reflect the effect of theadditional attribute in increasing, decreasing, or not affecting, theaverage base time requirement for the migration tasks during a migrationprocess. The effect of each additional attribute upon the base timerequirement for each migration task, and hence the development of eachcustomized time factor, ^(i)σ_(t), will be readily appreciated by thoseskilled in the art. Note that ^(i)σ₁ . . . ^(i)σ_(t) may differ for eachmigration task.

In accordance with step 1612, the time requirement for the migration isestimated. The calculation of estimated time is achieved by applying thetime factors assigned in step 1609 and the custom factors received instep 1610 to the base costs assigned in step 1605. Integrating the timefactors assigned for the code metrics returned in step 1608, and thecustom time factors received in step 1610, with the equations describedwith reference to FIG. 3, the time requirement f(t_(i)) for eachindividual migration task shown on the assessment template, other thanbaseline test and system test, is estimated as follows:

f(t _(i))=^(i) T ^(i)ψ_(S−T)(^(i) H ₁ ^(i) H ₂ . . . ^(i) H _(k))(^(i)θ₁ ^(i)θ₂ . . . ^(i)θ_(m))(^(i)

₁ ^(i)

₂ . . . ^(i)

_(n))(^(i)χ₁ ^(i)χ₂ . . . ^(i)χ_(p))(^(i)μ₁ ^(i)μ₂ . . . ^(i)μ_(q))(^(i)v ₁ ^(i) v ₂ . . . ^(i) v _(s))(^(i)σ₁ ^(i)σ₂ . . . ^(i)σ_(t))

The time requirement for baseline test is estimated as follows:

f(t ₂)=² T ²ψ_(S−T)(² H ₁ ² H ₂ . . . ² H _(k)) (²θ₁ ²θ₂ . . . ²θ_(m))(²

₁ ²

₂ . . . ²

_(n))(²χ₁ ²χ₂ . . . ²χ_(p))(²μ₁ ²μ₂ . . . ²μ_(q))(² v ₁ ² v ₂ . . . ² v_(s))(²σ₁ ²σ₂ . . . ²σ_(t))(² b ₁ . . . ² b _(r))

The time requirement for system test is estimated as follows:

f(t ₄)=⁴ T ⁴ψ_(S−T)(⁴ H ₁ ⁴ H ₂ . . . ⁴ H _(k)) (⁴θ₁ ⁴θ₂ . . . ⁴θ_(m))(⁴

₁ ⁴

₂ . . . ⁴

_(n))(⁴χ₁ ⁴χ₂ . . . ⁴χ_(p))(⁴μ₁ ⁴μ₂ . . . ⁴μ_(q))(⁴ v ₁ ⁴ v ₂ . . . ⁴ v_(s))(²σ₁ ⁴σ₂ . . . ⁴σ_(t))(⁴ b ₁ . . . ⁴ b _(r))

The time estimate for the migration process shown on the assessmenttemplate is estimated as follows:

$\sum\limits_{i = 1}^{i}{f\left( t_{i} \right)}$

In accordance with step 1613, desired tolerances are applied in themanner described with reference to FIG. 1. In accordance with step 1614,a Type A assessment is output, which shows estimated costs and/or timerequirements for the migration process and each migration task in theassessment template, given the base variables, attributes and codemetrics received. Any such estimates may be represented as fixed numbersor ranges. In the preferred embodiment of the invention, costs and/ortime requirements estimated in a Type A assessment are output as ranges,which are accurate within thirty percent (30%). More preferably, theestimates are accurate within fifteen to twenty-five percent (15-25%).

The invention is also directed to computer-readable program productshaving computer-readable program code means for producing cost and timerequirement estimates for migration projects, in accordance with thevarious embodiments of the method described herein. Selectingappropriate media and implementing the process described herein on suchmedia are matters that will be readily known to those skilled in theart.

While the foregoing material describes and illustrates the currentinvention with reference to particular embodiments, these embodimentsare intended as examples and not to define the entire scope of thecurrent invention. Those skilled in the art will appreciate that manyaspects of these embodiments may be changed and steps of the variousmethods re-arranged, such as creation of template, assignment of basecosts and receiving additional data, without departing from the spiritor scope of the invention.

1-46. (canceled)
 47. A method for estimating a cost and a duration formigrating a computer application from a source platform to a targetplatform, the method comprising: a computer receiving a request toestimate the cost and the duration for migrating the computerapplication, the request including an indication of a first, second orthird assessment type; and the computer receiving specification of (a) aplurality of migration attributes of the computer application, theplurality of migration attributes being associated with the firstassessment type, (b) a first subset of migration attributes that is lessthan all of the plurality of migration attributes, the first subset ofmigration attributes being associated with the second assessment type,the second assessment type being less accurate than the first assessmenttype, or (c) a second subset of migration attributes that is less thanall of the first subset of migration attributes, the second subset ofmigration attributes being associated with the third assessment type,the third assessment type being less accurate than the second assessmenttype, the plurality of migration attributes including a source codecorresponding to the computer application, the first subset of migrationattributes including a count of a number of lines in the source code,and the second subset of migration attributes including a type ofoperating system on which the computer application executes.
 48. Themethod of claim 47, further comprising: the computer receivingspecification of a set of tasks required for the migration; the computerdetermining, for each task, an average cost of completing the task andan average duration for completing the task; and the computer estimatingthe cost and the duration based at least in part on the average cost ofcompleting each task, the average duration for completing each task andone of the plurality of migration attributes, the first subset ofmigration attributes and the second subset of migration attributes; andthe computer determining and reporting to a user a degree of accuracyfor estimating the cost and the duration based at least in part on theassessment type.
 49. The method of claim 48, wherein the assessment typeis associated with a type of information to be migrated and an amount ofinformation to be migrated, the set of tasks including at least one of aplurality of first tasks, a plurality of second tasks and a plurality ofthird tasks, wherein the first assessment type is associated with a listof first tasks including the plurality of first tasks, the secondassessment type associated with a list of second tasks including theplurality of second tasks, and the third assessment type associated witha list of third tasks including the plurality of third tasks; andwherein the computer receiving the set of tasks includes the computerreceiving tasks from the one list of first tasks, list of second tasksand list of third tasks associated with the assessment type.
 50. Themethod of claim 49, wherein at least one task of the set of tasks is oneof user-defined and pre-defined in one of the list of first tasks, thelist of second tasks and the list of third tasks.
 51. The method ofclaim 48, wherein the average duration includes at least one of a numberof hours, a number of days, a start time and a finish time, the methodfurther comprising: the computer creating an assessment templateincluding each task in the set of tasks, the average cost of completingeach task and the average duration for completing each task.
 52. Themethod of claim 51, wherein the assessment template includes a breakdownof a cost of labor and a cost of materials; and wherein the plurality ofmigration attributes and the first subset of migration attributesinclude a source code attribute comprising at least one of a number ofcode modules, a number of files, call types, a number of calls, a datavolume, a structural integrity, a use of lexical functions and operatingsystem dependence; and when the assessment type is the first assessmenttype, the method further comprises: the computer determining source codemetrics based at least in part on an analysis of the source code. 53.The method of claim 48, wherein the average cost and the averageduration for each task is different depending on whether assessment typeis one of the first assessment type, the second assessment type and thethird assessment type.
 54. The method of claim 48, wherein estimatingthe cost and the duration further comprises: the computer determining acost factor by which at least one migration attribute of one of theplurality of migration attributes, the first subset of migrationattributes and the second subset of migration attributes one ofincreases and decreases the average cost of completing at least one taskof the set of tasks, the cost factor being different for each migrationattribute; the computer determining a time factor by which the at leastone migration attribute of one of the plurality of migration attributes,the first subset of migration attributes and the second subset ofmigration attributes one of increases and decreases the average durationof the at least one task in the set of tasks; and when the assessmenttype is the first assessment type, determining a custom factor by whichthe at least one migration attribute of one of the plurality ofmigration attributes, the first subset of migration attributes and thesecond subset of migration attributes one of increases and decreases theaverage cost and the average duration of the at least one task in theset of tasks.
 55. The method of claim 54, wherein estimating the costand the duration further comprises: the computer estimating the cost ofmigrating the computer application by multiplying the cost factor andthe average cost of completing each task in the set of tasks; andestimating the duration of migrating the computer application bymultiplying the time factor and the average duration of each task in theset of tasks.
 56. The method of claim 55, wherein the plurality ofmigration attributes, the first subset of migration attributes and thesecond subset of migration attributes include a hardware attribute, anoperating system attribute, an application attribute, an environmentattribute and a testing attribute, the method further comprising: thecomputer applying the degree of accuracy to the cost and the durationfor migrating the computer application.
 57. A computer program productfor estimating a cost and a duration for migrating a computerapplication from a source platform to a target platform, said computerprogram product being loaded on a computer system having a centralprocessing unit and comprising: a computer readable medium; firstprogram instructions to receive a request to estimate the cost and theduration for migrating the computer application, the request includingan assessment type, the assessment type being one of a first assessmenttype, a second assessment type and a third assessment type; secondprogram instructions to receive specification of (a) a plurality ofmigration attributes of the computer application, the plurality ofmigration attributes being associated with the first assessment type,(b) a first subset of migration attributes that is less than all of theplurality of migration attributes, the first subset of migrationattributes being associated with the second assessment type, the secondassessment type being less accurate than the first assessment type, or(c) a second subset of migration attributes that is less than all of thefirst subset of migration attributes, the second subset of migrationattributes being associated with the third assessment type, the thirdassessment type being less accurate than the second assessment type, theplurality of migration attributes including a source code correspondingto the computer application, the first subset of migration attributesincluding a count of a number of lines in the source code, and thesecond subset of migration attributes including a type of operatingsystem on which the computer application executes.
 58. The computerprogram product of claim 57, further comprising: third programinstructions to receive a set of tasks required for migration; fourthprogram instructions to determine, for each task, an average cost ofcompleting the task and an average duration for completing the task; andfifth program instructions to: estimate the cost and the duration basedat least in part on the average cost of completing each task, theaverage duration for completing each task and one of the plurality ofmigration attributes, the first subset of migration attributes and thesecond subset of migration attributes; and determine and report to auser a degree of accuracy for estimating the cost and the duration basedat least in part on the assessment type.
 59. The computer programproduct of claim 58, wherein each assessment type is associated with atype of information to be migrated and an amount of information to bemigrated, the set of tasks including at least one of a plurality offirst tasks, a plurality of second tasks and a plurality of third tasks,wherein the first assessment type is associated with a list of firsttasks including the plurality of first tasks, the second assessment typeassociated with a list of second tasks including the plurality of secondtasks, and the third assessment type associated with a list of thirdtasks including the plurality of third tasks; and the third programinstructions further include instructions to receiving tasks from theone list of first tasks, list of second tasks and list of third tasksassociated with the assessment type.
 60. The computer program product ofclaim 59, wherein at least one task of the set of tasks is one ofuser-defined and pre-defined in one of the list of first tasks, the listof second tasks and the list of third tasks.
 61. The computer programproduct of claim 58, wherein the average duration includes at least oneof a number of hours, a number of days, a start time and a finish time;and the fifth program instructions further include instructions tocreate an assessment template including each task in the set of tasks,the average cost of completing each task and the average duration forcompleting each task.
 62. The computer program product of claim 61,wherein the assessment template includes a breakdown of a cost of laborand a cost of materials; and wherein the plurality of migrationattributes and the first subset of migration attributes include a sourcecode attribute comprising at least one of a number of code modules, anumber of files, call types, a number of calls, a data volume, astructural integrity, a use of lexical functions and operating systemdependence; and when the assessment type is the first assessment type,said second program instructions further include instructions to:determine source code metrics based at least in part on an analysis ofthe source code.
 63. The computer program product of claim 58, whereinthe average cost and the average duration for each task is differentdepending on whether assessment type is one of the first assessmenttype, the second assessment type and the third assessment type.
 64. Thecomputer program product of claim 58, wherein said fifth programinstructions further include instructions to: determine a cost factor bywhich at least one migration attribute of one of the plurality ofmigration attributes, the first subset of migration attributes and thesecond subset of migration attributes one of increases and decreases theaverage cost of completing at least one task of the set of tasks, thecost factor being different for each of the migration attributes;determine a time factor by which the at least one migration attribute ofone of the plurality of migration attributes, the first subset ofmigration attributes and the second subset of migration attributes oneof increases and decreases the average duration of the at least one taskin the set of tasks; and when the assessment type is the firstassessment type, determine a custom factor by which the at least onemigration attribute of one of the plurality of migration attributes, thefirst subset of migration attributes and the second subset of migrationattributes one of increases and decreases the average cost and theaverage duration of the at least one task in the set of tasks.
 65. Thecomputer program product of claim 64, wherein said fifth programinstructions further include instructions to: estimate the cost ofmigrating the computer application by multiplying the cost factor andthe average cost of completing each task in the set of tasks; andestimating the duration of migrating the computer application bymultiplying the time factor and the average duration of each task in theset of tasks.
 66. The computer program product of claim 65, wherein theplurality of migration attributes, the first subset of migrationattributes and the second subset of migration attributes include ahardware attribute, an operating system attribute, an applicationattribute, an environment attribute and a testing attribute, and saidfifth program instructions further include instructions to: apply thedegree of accuracy to the cost and the duration for migrating thecomputer application.